This PR introduces a new metric, agent_sandbox_claim_controller_startup_latency_ms, to provide higher precision tracking of SandboxClaim startup performance.

Problem

Currently, startup latency is measured using the standard Kubernetes creationTimestamp. However, this timestamp has one-second granularity. For fast-provisioning resources like SandboxClaims, where target latencies are often in the millisecond range, this granularity is too coarse and leads to inaccurate P50/P90 metrics.

Proposed Solution

The controller now stamps a high-precision controller-first-observed-at annotation during its first reconciliation cycle. The new metric measures the duration from this observation point to the "Ready" state.

Notes for the reviewer

• Measures Controller-Observed Latency: This tracks the duration from the controller's first observation to the "Ready" state, rather than total client-perceived creation time. (A separate SDK metric will be created to track the full client-to-Ready latency).
• Excludes Pre-Reconciliation Overhead: It omits initial API server processing, watch latency, and workqueue delays occurring before the first reconciliation cycle. This makes it a "partial" server-side metric focused strictly on controller performance.
• Requires Inline Patching: Recording the high-precision timestamp adds an extra API call (inline patch) during the first reconciliation. To minimize API overhead, this is bundled with the tracing annotation patch whenever tracing is enabled.